home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Aminet 20
/
Aminet 20 (1997)(GTI - Schatztruhe)[!][Aug 1997].iso
/
Aminet
/
dev
/
debug
/
MemSniff.lha
/
Memsniff
/
BugReport
next >
Wrap
Text File
|
1997-05-25
|
3KB
|
67 lines
Howdy!
I have to apologize for the broken 1.09 release of MemSniff - it caused
really a lot of crashes. After a long debug session for over eight hours
it turned out that this problem was not caused by MemSniff, but by
"MagicMenu" !
So here's what was going on:
The workbench task displays the size and free storage of available volumes
in the title bar of the workbench windows. To avoid memory defragmentation,
the algorithm of updating this title bar works like this:
- Determinate the total size and the number of available blocks of
all devices.
- Create a new window title from the new information.
- Allocate new memory to hold the new title.
- Read the title bar pointer from the workbench window (this is important!)
and compare the current title bar string with the old one.
If nothing changed, free the new title (to avoid defragmentation) and
leave the title alone.
- If the title has changed: Read the title bar string pointer from the
workbench window (!) free it and set the new window title to the new
string.
This is the point of the operation where MagicMenu interacts, as the
SetWindowTitle() procedure is patched to a private MagicMenus procedure.
It calls here TypeOfMem() to determinate the memory type of the new string
to display as memory title. I've no idea why this is necessary or what this
should be good for since resident titles in the ROM are totally legal.
Anyways, if the title is not in valid RAM, the SetWindowTitle() operation
is aborted, no idea why.
Since MemSniff divides the total system memory in two parts, giving one to
the system and checking the other, it might well happen that the pointer
to the new window title is NOT in system memory, but in this part of the
memory that is currently checked by MemSniff. As a result, TypeOfMem()
returns zero, as it should do. As a result, MagicMenu aborts the
SetWindowTitle() call (no idea why) and leaves the old string pointer in
the window structure. This old window title will, however, get FreeVec()'ed
by the workbench on the next step, but since MagicMenu aborts the
SetWindowTitles(), this invalid pointer is now still in the window structure.
On the next refresh, the workbench reads this invalid pointer, by assuming
it is the last successfully installed window title - which is not true since
MM canceled this operation - and tries to free it: ZAPPO!
This bug was not at all obvious, and I would say aborting the
SetWindowTitles() operation by MagicMenu just like because the memory
type was unkown is more than delicate. At LEAST, the new window title pointer
should get installed in the window structure to make the workbench working
in all cases. Remember, titles in the ROM are absolutely legal and I don't
see a reason why MagicMenu aborts their installation. Anyways, I added a
workaround for this behaiviour in the current release of MemSniff, so this
problem is definitely fixed now.
I have really to apologize to all those people who tried to run MemSniff and
where disappointed by its unstability. Sorry, sorry, sorry, guys!
Greetings,
Thomas